1. Field of the Invention
The present invention relates to computer security. More particularly, the present invention relates to timing attacks against user logon and network I/O.
2. Background
Network security solutions have often focused on cryptographic protocols, their security properties, and key management for these protocols. Another important area to consider with respect to network security is the security of user host systems or workstations. If the user system security is weak, then the user's network identity can be stolen by an attacker, or used in ways not intended by the user. If the user is an administrator, then the attacker may be able to compromise the data of many network users.
A Trojan horse is a program routine that invades a computer system by being secretly attached to a valid program that will be downloaded into the computer. It may be used to locate password information, or it may alter an existing program to make it easier to gain access to it. Typically, a Trojan horse runs with the identity and all the rights of the user. A virus is a Trojan horse that continues to infect programs over and over.
With the advent of the World Wide Web (WWW) and Java, an attacker has many opportunities to push Trojan horses down to the user's desktop system. WWW browsers invoke helper applications that are potential Trojan horse processes. For example, the Felten-Balfanz attack can be used to launch a Word macro virus on a client host if the user visits the attacker's web page. Mail programs with attachments can also lead to a Trojan horse running on the user's system. Java applets may be Trojan horses. Push technology is likely to increase the ability of an attacker to target a particular user.
User systems that are Trojan horse non-persistent are less vulnerable to attacks. A user system is Trojan horse non-persistent if a downloaded Trojan horse process cannot survive a reboot. More specifically, a user system is Trojan horse non-persistent if:    1. A downloaded Trojan horse program cannot arrange to have itself restarted by the operating system after reboot, and    2. A downloaded Trojan horse program cannot arrange to be invoked when the user invokes a program from his/her normal set of programs assuming the downloaded program has not been added to the normal set of user programs by either the user or an administrator.
Windows 95 is an example of a user system that is not Trojan horse non-persistent, since this host would fail both (1) and (2) above. On a Windows 95 system, a downloaded Trojan horse can arrange to restart itself on an operating system reboot. A Trojan horse can also infect any program in the user's normal set of programs. These facts are a consequence of the lack of access control in Windows 95.
UNIX and Windows NT operating systems are potentially Trojan horse non-persistent, but in practice, many of these systems do not have this property. For example, on many UNIX hosts, the user PATH environment variable is writable by the user. Thus, a downloaded Trojan horse can reorder the list of directories to be searched on invocation of an executable specified by a relative file name. The result can be that the user executes a Trojan horse program instead of the mail program from his/her normal set of programs. Note that Windows NT and UNIX are designed to have property (1) above; a failure to have this property is typically a result of complete system penetration (the attacker becoming superuser or administrator).
On Windows NT systems, the user profile contains files that contain the names of executables that are invoked when the user selects the corresponding desktop icons with the mouse. These files are often configured as writable by the owning user. Therefore, a downloaded Trojan horse could rewrite a link in one of these files so that the user invokes a Trojan horse browser instead of his/her normal browser, violating property (2) above.
The above scenarios on Windows NT and UNIX are a result of the fact that the administration load is lightened if the user is allowed to do some administration himself/herself. For example, a UNIX user may need to add a directory to his/her path in order to run a certain program. If he/she can change the PATH environment variable, then the administrator is saved from having to do it
The UNIX “setuid” command assigns the identity and all associated rights of a user to a process. The lack of adequate access control is complicated by the fact that a setuid mechanism solution is vulnerable to the case where a Trojan horse invokes the setuid program. An improvement is possible by making the privileges of each process equal to the intersection of the ones associated with the executable file and the process's parent process (as in UNIX System V, Release 4.1); the PATH file change utility would therefore be able to modify the PATH file and other user processes would be unable to spawn this process or modify the PATH file themselves. Another improvement is possible by making the PATH file change utility setuid to a non-human user that has the needed privilege to invoke the trusted path mechanism. The trusted path mechanism then acts as a go-between between the user and the change utility (the change utility uses it as the user interface).
Typically, the UNIX setuid mechanism allows for more fine-grained access control on the UNIX operating system than what is available on Windows NT. A weakness of Windows NT is that all processes belonging to a user run with the same privileges and access rights.
Many commercial UNIX systems also have the following additional weakness with respect to downloaded Trojan horses. A downloaded Trojan horse can make the necessary system calls to become a daemon process (such as setpgrp) and continue to run unattended after the user has logged out Such a process runs until the system is rebooted.
The term “Trusted path” refers to a secure trusted communication path between a user and trusted software on the user's system. A system with a trusted path mechanism ensures that the user password is not handed directly to a Trojan horse. The TCSEC (Orange Book) defines the concept of trusted path at the B2 level. Department of Defense Trusted Computer System Evaluation Criteria, DOD 5200.28-STD. Fort Meade, Md. National Computer Security Center, December 1985. For B2 trusted path, the user must be able to involve a trusted path between himself and the operating system kernel at login time. Thus, the user can ensure that he/she is not being spoofed by a password gathering Trojan horse, and that the password is not being handled by untrusted software between keyboard entry and the kernel.
The Windows NT operating system has the B2 trusted path property that is invoked with the control-alt-delete keys. Trusted path is also invoked when locking and unlocking the workstation. UNIX System V Release 4.1 is designed with the trusted path feature, but many of the commercially popular UNIX operating systems do not have the trusted path feature.
On UNIX systems without the trusted path mechanism, the “su” command is vulnerable to attack. The X windows user interface is easily spoofed. For instance, a Trojan horse might be programmed to act like the X windows lockscreen program in an attempt to gather passwords. Thus a Trojan horse on such a system can obtain the root password, even if the system is Trojan horse non-persistent
UNIX systems without trusted path do have the equivalent of the trusted path mechanism, but only under a limited set of circumstances. Here, the user only enters his/her logon password during the initial logon sequence and the user does not use the “su” command. Since the logon password is entered only once, the user does not use the X windows lockscreen feature.
Typically, commercial client operating systems lack the fine grain access control necessary to protect against Trojan horse attacks. These systems fail to adequately manage permissions for logging onto system and/or making modifications to the computer user environment, making the systems susceptible to attack. Even systems employing the “trusted path” concept are vulnerable to attack. Accordingly, a need exists in the prior art for a method for protecting against Trojan horse attacks against computer operating systems employing a trusted path mechanism.